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(5) If no "from domain" is found, apply the local policy. 

(6) Query for the public key component based on the 
signature type, selector, the "from domain," and the like. In 
the case of the DNS, the query may be of the form of a TXT 
record for the name $selector._smtp._domainkey.$fromdo- : 
main, or the like. 

(7) If the query fails to respond, defer acceptance of this 



(8) If the query fails because the record does not exist, 
apply the local policy. to 

As an interim until widely adopted, the Domain Key 
application can use a place-holder DNS entry at the _smt- 
p._domainkey.node which indicates whether that particular 
domain is participating in the Domain Key application or 
not. The presence of the place-holder indicates participation 15 
while the absence of the place-holder indicates non-partici- 
pation. 

(9) Using the public key component returned from the 
query, check the signature against the entire contents o f the 
email following the "DomainKey-^ 



lature: "headerl line. 20 

Again, the contents are canonically treated in exactly the 
same way as they are in the signing process. 

(10) If the digital signature fails, apply local policy. 

(11) In all cases where the message is accepted for 
delivery, local policy may be conveyed to the message client 25 
via a "DomainKey-Status:" header line that precedes the 
fpomainKey-Signature:" header line. 

EXAMPLES ^ 

The following example for the Domain Key application is 
intended to introduce at least one embodiment of the present 
invention and illustrate how its concepts may be integrated 
into a flow of email. 

35 

Email Composed by User 

From: "Joe SixPack"<joe@football.example.com> 
To: "Suzie Q"<suzie@shopping.example.net> 
Subject: Is dinner ready? 

Date: Fri, 11 Jul. 2003 21:00:37-0700 (PDT) 40 
Message-ID: 

<200307 12040037.4634 1.5F8J@football.example.com> 
Hi. 

We lost the game. Are you hungry yet? 
Joe. ' 45 

Nothing about the email authorship process is changed by 
the Domain Key application. In some implementations it is 
expected that the sender may have no need to know that the 
Domain Key application exists. 

50 

Email Signed by Sending Email Server 

Using the private key component, this email is signed by 
the example.com outbound mail server and now looks 
something like this: 
DomainKey-Signature: 55 
sigs-0.50:D8CD98F00B204E98: 
AMLfamjh4GrUzSN5BeUC13qwlq/hL6 GOk8M/ 
lUNjSRruBNmRugCQoX7/ 
mHSbSF5Dimr5ey 1 K6MZg0XclZucPW/s9UWm/ 
mxqWP 5uD42B6G+MbSicsj/2o bMIBIQ jNzRX7A 60 
|!9rOUi4| NFzi DVtQ74vgMlMJepyJB |3NOq jfan8zGe+g 
XhcNBbCuxE0T2keDkJQP8ZJtl WL+ 
t6IhbTX3vWxtK0CtjaXYCxVJ5IoyroMxfpdwU6dolfEa 
bodyC 1 Tu+9xvOfHVK+JK7rz+ 

wwbvRrxiLfrTigYTm4TQ9vlHkW9nt9/7aLw/rN2Fs/ 65 
kGwKM ZwxQ9ypgi9qOpNX/TAceE10p8+ 
jAXW70R7pZYzdrNTq0/IfZu76nq6YnQux7 



Received: from dsl-10.2.3.4.network.example.com 
[10.2.3.4] by submitserver.example.com with SUB- 
MISSION; 
Fri, 11 Jul. 2003 21:01:54-0700 (PDT) 
From: "Joe SixPack"<joe@football.example.com> 
To: "Suzie Q"<suzie@shopping.example.net> 
Subject: Is dinner ready? 
Date: Fri, 11 Jul. 2003 21:00:37-0700 (PDT) 
Message-ID: <20030712040037 .46341. 5F8J@football. 

example.com> 
Hi. 

Here we can see that additional header lines have been 
added to this email. Of particular interest are the contents of 
the "DomainKey-Signature:" line, which has three colon 
separated components: 

(1) A digital signature type and version — in this case 
"sigs-0.50". This defines which algorithm is used to check 
the signature. It also defines the location and form of the 
query used to retrieve the corresponding Public Key. 

(2) The Domain Key Selector— in this case 
"D8CD98F00B204E98". This selector is used to form a 
query for the Public Key. It is understood that a selector can 
be provided by which multiple Public Keys for a single 
domain name might co-exist. 

(3) The digital signature data encoded as a base64 
string — in this case the string starting with 
"AMLfamjh4GrUzSN". This is the output of the digital 
signature generation process. 

White spaces are typically ignored in this header and may 
be removed when using the components to verify the email. 
The signature typically applies to every line following the 
first "DomainKey-Signature:" header line. 

Note that as some email systems re-write headers, it may 
be appropriate to sign a canonical form of vulnerable 
headers and sign a specific subset of header. 

Authentication of Email by Receiving Email Server 

For an email, the digital signature is normally authenti- 
cated by the final delivery agent. However, intervening mail 
servers may also perform this authentication if they choose 
to do so. 

One embodiment of a process for authentication includes 
the following steps: 

(1) The selector and digital signature are extracted from 
the "DomainKey-Signature:" header line. 

(2) The domain is extracted from the sender address. This 
is the contents of the first "From:" header. If no domain can 
be extracted, then extract from the first "Sender:" header 
line. If no domain can be extracted then the domain is 
extracted from the envelope sender. 

(3) The DNS is queried for a TXT record associated with 
the following name: 

D8CD98F00B204E98._smtp._domainkey.example.com 
Note that the selector "D8CD98F00B204E98" forms part 
of the DNS query as part of the Domain Key process. 

(4) The returned TXT record includes the base64, or the 
like, encoded Public Key for that selector/domain combina- 
tion. This Public Key may be used to authenticate the digital 
signature according to the Signature type and version algo- 
rithm. 

(5) If no TXT record exists, the digital signature is a 
forgery or this Domain key pair has been revoked by the 
domain owner. 
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17. The method of claim 1, wherein employing the policy, 
further comprises if it is determined that the domain is 
relatively new to a messaging system, employing a new 
domain policy for handling an amount of verified digitally 
signed messages that are less than a predetermined limit 5 
over a period of time, wherein each message that is greater 
than the predetermined limit is handled with at most partial 
rejection. 

18. The method of claim 1, further comprisingj] 
generating a personal digital certificate for the sender to 

based on the public component and the private com- 
ponent of the key pair associated with the domain; 

providing a public component of the personal digital 
certificate to the recipient along with the verified digi- 
tally signed message; and 15 

enabling the recipient to subsequently provide a response 
message to the sender that is automatically encrypted 
with the public component of the sender's personal 
digital certificate. 

19. The method of claim 18, wherein the personal digital 20 
certificate is associated with an address of the sender. 

20. A server for message authentication, comprising: 
a memory for storing instructions; 

a processor for enabling actions based on the stored 
instructions, including: 25 
generating a key pair associated with a domain, 
wherein a public component of the key pair is 
accessible to a domain name system (DNS) server 
that is associated with the domain; 
if a message originates from a sender's address asso- 30 
ciated with the domain, employing a private com- 
ponent of the key pair to digitally sign the message 
and forwarding the digitally signed message towards 
a recipient of the message; and ^ 
if the public component stored with the DNS server 
verifies that the digitally signed message originated 
from the domain associated with the sender's 
address, employing at least one policy associated 
with the originating domain to handle the verified ^ 
digitally signed message for the recipient; 
else handling the message from another sender's 
address associated with an unverified domain. 

21 . The server of claim 20, wherein the at least one policy 
includes at least one of an unverified domain policy, a 45 
verified domain policy, a new domain policy, a system 
policy, a user policy, a statistics policy, and a third party 
policy. 

22. The server of claim 20, the actions further comprising: 
generating a personal digital certificate for the sender 50 

based on the public component and the private com- 
ponent of the key pair associated with the domain, 
wherein the personal digital certificate is associated 
with an address of the sender; 

providing a public component of the personal digital 55 
certificate to the recipient along with the verified digi- 
tally signed message; and 

enabling the recipient to subsequently provide a response 
message to the sender that is automatically encrypted 
with the public component of the sender's personal 60 
digital certificate. 

23. A client for message authentication, comprising: 
a memory for storing instructions; 

a processor for enabling actions based on the stored 
instructions, including: 65 
generating a key pair associated with a domain, 
wherein a public component of the key pair is 



accessible to a domain name system (DNS) server 
that is associated with the domain; 

if a message originates from a sender's address asso- 
ciated with the domain, employing a private com- 
ponent of the key pair to digitally sign the message 
and forwarding the digitally signed message towards 
a recipient of the message; and 

if the public component stored with the DNS server 
verifies that the digitally signed message originated 
from the domain associated with the sender's 
address, employing at least one policy associated 
with the originating domain to handle the verified 
digitally signed message for the recipient; 

else handling the message from another sender's 
address associated with an unverified domain. 

24. The client of claim 23, wherein the at least one policy 
includes at least one of an unverified domain policy, a 
verified domain policy, a new domain policy, a system 
policy, a user policy, a statistics policy, and a third party 
policy. 

25. The client of claim 23, the actions former comprising: 
generating a personal digital certificate for the sender 

based on the public component and the private com- 
ponent of the key pair associated with the domain, 
wherein the personal digital certificate is associated 
with an address of the sender; 

providing a public component of the personal digital 
certificate to the recipient along with the verified digi- 
tally signed message; and 

enabling the recipient to subsequently provide a response 
message to the sender that is automatically encrypted 
with the public component of the sender's personal 
digital certificate. 

26. A computer readable storage medium that includes 
instructions for performing actions, comprising: 

generating a key pair associated with a domain, wherein 
a public component of the key pair is accessible to a 
domain name system (DNS) server that is associated 
with the domain; 

if a message originates from a sender's address associated 
with the domain, employing a private component of the 
key pair to digitally sign the message and forwarding 
the digitally signed message towards a recipient of the 
message; and 

if the public component stored with the DNS server 
verifies that the digitally signed message originated 
from the domain associated with the sender's address, 
employing at least one policy associated with the 
originating domain to handle the verified digitally 
signed message for the recipient; 

else handling the message from another sender's address 
associated with an unverified domain. 

27. The computer readable storage medium of claim 26, 
the actions further comprising: 

a personal digital certificate for the sender 
the public component and the private com- 
ponent of the key pair associated with the domain, 
wherein the personal digital certificate is associated 
with an address of the sender; 
providing a public component of the personal digital 
certificate to the recipient along with the verified digi- 
tally signed message; and 
enabling the recipient to subsequently provide a response 
message to the sender that is automatically encrypted 
with the public component of the sender's personal 
digital certificate. 



